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Commissioner for Patents 
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Alexandria, VA 2231 3-1 450 

Sir: 

Pursuant to the Pre-Appeal Brief Conference Pilot Program, and further to the 
Examiner's Final Office Action dated June 10, 2008, Applicant files this Pre-Appeal Brief 
Request for Review. This Request is also accompanied by the filing of a Notice of Appeal. 

Turning to the rejection at issue, claims 1-4 are rejected under 35 U.S.C. 103(a) as 
allegedly being unpatentable over Draves in view of Kavanagh and Moore, (see Final Office 
Action, P. 4 for full citation). Applicant respectfully submits that the cited combination of 

references fails to teach or suggest at least a DNS server comprising: 

address sequencing means, for sequencing, as a function of |an] address of the first network 
element, a plurality of IPv6 addresses associated with said second network element, and for 
putting one or more IPv6 addresses associated with said second network element in the 
order of the sequence in said response [to a request identifying the first network element] 

First, as detailed in Applicant's Amendment under 37 C.F.R. § 1.111 filed February 26, 
2008, Kavanagh fails to teach or suggest anything regarding a " plurality of [J addresses [of] a 
given network element ." When Kavanagh refers to a plurality of addresses, those belong to 
different network elements . ( Kavanagh, col. 5, Ins. 1-4; col. 9, Ins. 9-15). Indeed, the entities 
that are subjected to preference ordering are respective nodes represented by respective 
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addresses . (Kavanagh, col. 2, Ins. 1-11). Thus, Kavanagh sequences addresses of " a plurality 
of nodes " and not a plurality of IPv6 addresses fofl a given network element . 

Second, in the Advisory Action, the Examiner asserted that Draves merely fails to 
"expressly" disclose the sequencing being performed on a DNS server. (Advisory Action, P. 2). 
However, Applicant respectfully submits that Draves explicitly discloses the sequencing being 
performed on a node, not the DNS server . In particular, in paragraphs 3 and 4 of section 1, 
Draves teaches that a node queries a DNS server to resolve a given name. Then, the DNS returns 
a set of addresses comprising.a global IPv6 address and a global IPv4 address. Then, the node 
uses a destination address selection algorithm for choosing among the set of addresses. 
Therefore, it is clear that the node applies the destination ordering rules in section 6 to the set of 
addresses returned by the DNS, not the DNS. 

To supplement for this deficiency, the Examiner asserted that Moore would have 
motivated the skilled artisan to have the DNS server perform the sequencing of the addresses. 
However, Applicant submits that Moore fails to teach anything specific to a DNS server. 

First, the socket getaddrinfo() is a generic function through which an application requests 
an operating system to convert a name into an address. Applicant submits that getaddrinfo() is 
not at all specific to DNS servers . It is implemented by a variety of network elements, 
including any IP host, through a variety of lower layer functions. 

Second, the Examiner asserted that the following statement would indicated to the skilled 

artisan that sequencing should be performed on a DNS server: 

[Wjhat is needed is to stop relying so much on applications/hosts choosing destination addresses. 
Hosts should have as few addresses as possible. The network should make a best effort to 
deliver the traffic to whatever address is used over the links permitted for such use . 

Applicant respectfully submits that the Examiner has read this statement in hindsight. In 
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particular, Applicant respectfully submits that Moore was merely stating that the number of 
addresses returned by the network should be reduced. (Moore, Lns. 7-9, "Hosts should have as 
few addresses as possible , , , links permitted for such use.")- Nothing in the above 
statement mentions the DNS server sequencing, "as a function of lanl address of the first 
network element"; a plurality of addresses of a second network element and "putting 
[plurality of addresses! in the order of the sequence in [a] response . Moore simply indicated 
that the reliance on the host (i.e. node) should be reduced by reducing the number of addresses 
from which the nodes had to choose. However, clearly, Moore was still suggesting that the 
application/hosts choose destination addresses. (Moore, Lns. 6, "stop relying so much ".) 

Applicant now turns to the whole thread of e-mails from which MOORE's disclosure is 
extracted in order to clarify the technical content of this disclosure in view of the context in 
. which it appeared, (see http://www.ops.ietf.Org/lists/v6ops/v6ops.2002/maillist.html#00887) . 

Looking at the date index of the thread, the discussion "Re: getaddrinfo address ordering" 
starts with message number #00856, dated 27 Nov 2002 09:22:04 +0200 and ends with message 
#00887, dated 28 Nov 2002 08:01 :39 -0500. The discussion comprises 26 messages. 

The discussion starts on the topic of enhancing a getaddrinfo resolver in an IP host (we 
would want to add some extra smarts to getaddrinfo). The resolver is called by an application 
(you need the address ordering to be sensitive to both network configuration and to the 
particular application.) The resolver is processing DNS records returned by a DNS server with 
some default ordering. The getaddrinfo resolver at the IP host is intended to return the records to 
the calling application with a potentially different order (you want to influence the default DNS 
record ordering). Thus, the discussion initially focuses on an IP host, e.g. a DNS client, and an 
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application run thereon. Besides, this initial focus remains the same for the next 23 messages, 
until message #00883. Also, it is noteworthy that message #00860 explicitly refers to Draves. 

In Message #00867, MOORE gives his own vision of how the network could help in the 
process of address ordering. The local network would provide the IP host with a configuration 
tile that specifies the preferred ordering (eventually it might be nice if the host could get that 
preference list from the local network). 

Actually messages #00878 and #00883 focus on the application run by the IP host. 

Then for the first time in message #00886, the focus is shifted from the IP host to "some 
server". However, YOSHIFUJI's statement is very elliptical. No information is provided about 
the undefined server. This statement starts to broaden the focus of the discussion but does not 
provide any clear direction. It is worth noting that no-one in the recipients elaborated on 
YOSHIFUJI's idea. This may indicate that YOSHIFUJI's statement was not even understood. 

MOORE' s response in message #00887 does not elaborate on "some server selection 
method". Quite oppositely, it broadens the discussion one step further by referring to "the 
network" as a whole, which implies that the focus proposed by YOSHIFUJI's was either not 
understood or not considered relevant by MOORE. It is worth noting that MOORE's message 
#00867 already specified the way the network could contribute to address selection. By referring 
to the network, message #00887 appears to hint at that earlier post by the same author. 

Besides, MOORE's last message further broadens the topic of the discussion from 
address selection to delivery of traffic (to deliver the traffic to whatever address is used over the 
links permitted for such use.) Hence it presents a broad perspective in a way that typically ends a 
discussion without deciding any practical conclusion or action point. Indeed no one responded. 
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From this whole thread, the person skilled in the art was not incited to change the 
operation of a DNS server in any way. As far as DNS servers are considered, the default 
ordering is assumed to be used. Further YOSHIFUJFs statement is not enabling and fails to 
point to any specific server whereas possibilities are innumerable (e.g. a server dedicated to 
selection services). Thus, the Examiner cannot assert that YOSHIFUJI was inherently referring 
to a DNS server. 

As such, Applicant respectfully submits that, in the context in which Moore was written, 
Moore clearly fails to teach or suggest that a DNS server should be modified to sequence a 
plurality of addresses as claimed. 

Thus, Applicant respectfully submits Draves in view of Kavanagh and Moore fail to 
teach or suggest at least a DNS server sequencing, "as a function of f anl address of the first 
network element", a plurality of addresses of a second network element and "putting 
[plurality of addressesl in the order of the sequence in fal response . 

As such, Applicant respectfully submits that claims 1 -4 would not have been obvious 
under 35 U.S.C. § 103(a). Accordingly, Applicant respectfully requests the Examiners withdraw 
the rejection of claim 1 and claims 2-4 at least by virtue of their dependency from claim 1 . 

Respectfully submitted, 

/Logan J. Brown 58.290/ 
SUGHRUE MION, PLLC Logan J. Brown 

Telephone: (202) 293-7060 Registration No. 58,290 

Facsimile: (202) 293-7860 

WASHINGTON OFFICE 

23373 

CUSTOMER NUMBER 

Date: December 10,2008 



5 



